검색결과
-
[특집-기술위원회] TC 215 - 의료 정보학(Health informatics)스위스 제네바에 본부를 두고 있는 국제표준화기구(ISO)에서 활동 중인 기술위원회(Technical Committeee, TC)는 TC 1~TC 323까지 구성돼 있다.기술위원회의 역할은 기술관리부가 승인한 작업범위 내 작업 프로그램 입안, 실행, 국제규격의 작성 등이다. 또한 산하 분과위원회(SC), 작업그룹(WG)을 통해 기타 ISO 기술위원회 또는 국제기관과 연계한다.ISO/IEC 기술작업 지침서 및 기술관리부 결정사항에 따른 ISO 국제규격안 작성·배포, 회원국의 의견 편집 등도 처리한다. 소속 분과위원회 및 작업그룹의 업무조정, 해당 기술위원회의 회의 준비도 담당한다.1947년 최초로 구성된 나사산에 대한 TC 1 기술위원회를 시작으로 순환경제를 표준화하기 위한 TC 323까지 각 TC 기술위원회의 의장, ISO 회원, 발행 표준 및 개발 표준 등에 대해 살펴볼 예정이다.이미 다룬 기술위원회와 구성 연도를 살펴 보면 △1947년 TC 1~67 △1948년 TC 69 △1949년 TC 70~72 △1972년 TC 68 △1950년 TC 74 △1951년 TC 76 △1952년 TC 77 △1953년 TC 79, TC 81 △1955년 TC 82, TC 83 △1956년 TC 84, TC 85 △1957년 TC 86, TC 87, TC 89 △1958년 TC 91, TC 92 △1959년 TC 94 △1960년 TC 96, TC 98 △1961년 TC 101, TC 102, TC 104 등이다.또한 △1962년 TC 105~107 △1963년 TC 108~111 △1964년 TC 112~115, TC 117 △1965년 TC 118 △1966년 TC 119~122 △1967년 TC 123 △1968년 TC 126, TC 127 △1969년 TC 130~136 △1970년 TC 137, TC 138, TC 142, TC 145 △1971년 TC 146~150, TC 153 △1972년 TC 154 △1973년 TC 155 △1974년 TC 156~161 △1975년 TC 162~164 등도 포함된다.그리고 △1976년 TC 165, TC 166 △1977년 TC 167, TC 168, TC 170 △1978년 TC 171~174 △1979년 TC 176, TC 178 △1980년 TC 180, TC 181 △1981년 TC 182 △1983년 TC 183~186 △1984년 TC 188 △1985년 TC 189~191 △1988년 TC 192~194 △1989년 TC 195 △1990년 TC 197, TC 198 △1991년 TC 199, TC 201, TC 202 △1992년 TC 204~206 △1993년 TC 209 △1994년 TC 210, TC 211 △1996년 TC 213, TC 214 등이 있다.ISO/TC 215 의료 정보학(Health informatics)과 관련된 기술위원회는 1998년 결성됐다. 사무국은 미국 표준협회(American National Standards Institute, ANSI)에서 맡고 있다.위원회는 레이첼 호손(Ms Rachel Hawthorne)가 책임지고 있다. 현재 의장은 토드 쿠퍼(Mr Todd Cooper)이며 임기는 2026년 말까지다. ISO 기술 프로그램 관리자는 마호 다카하시(Mme Maho Takahashi), ISO 편집 관리자는 발레리아 아가넨노네(Ms Valeria Agamennone) 등이다.범위는 의료 관련 데이터, 의료 시스템의 모든 측면을 지원하고 활성화하는 지식의 수집, 교환 및 사용을 촉진하기 위한 의료 정보학 분야의 표준화다.현재 ISO/TC 215 사무국과 관련해 발행된 표준은 237개며 ISO/TC 215 사무국의 직접적인 책임 하에 발행된 표준은 225개다.ISO/TC 215과 관련해 개발 중인 표준은 64개며 이중 ISO/TC 215 사무국의 직접적인 책임 하에 개발 중인 표준은 62개다. 참여하고 있는 회원은 35개국, 참관 회원은 32개국이다.□ ISO/TC 215 사무국의 직접적인 책임 하에 발행된 표준 225개 중 15개 목록▷ISO 1828:2012 Health informatics — Categorial structure for terminological systems of surgical procedures▷ISO/TR 4421:2023 Health informatics — Introduction to Ayurveda informatics▷ISO/TS 5044:2023 Health informatics — Information model for quality control of traditional Chinese medicinal products▷ISO/TS 5118:2022 Health informatics — Categorial structure of representation for evaluation of clinical practice guidelines of traditional Chinese medicine▷ISO/TS 5346:2022 Health informatics — Categorial structure for representation of traditional Chinese medicine clinical decision support system▷ISO 5477:2023 Health informatics — Interoperability of public health emergency preparedness and response information systems▷ISO/TS 5499:2024 Health informatics — Clinical particulars — Core principles for the harmonization of therapeutic indications terms and identifiers▷ISO/TS 5568:2022 Health informatics — Traditional Chinese medicine — Labelling metadata of human biological sample information▷ISO/TS 5569:2023 Health informatics — Conceptual data model for Chinese medicinal herbs▷ISO/TR 9143:2023 Health informatics — Sex and gender in electronic health records▷ISO 10159:2011 Health informatics — Messages and communication — Web access reference manifest▷ISO 10781:2023 Health informatics — HL7 Electronic Health Record-System Functional Model, Release 2.1 (EHR FM)▷ISO/IEEE 11073-00103:2015 Health informatics — Personal health device communication — Part 00103: Overview▷ISO/IEEE 11073-10101:2020 Health informatics — Device interoperability — Part 10101: Point-of-care medical device communication — Nomenclature▷ISO/IEEE 11073-10102:2014 Health informatics — Point-of-care medical device communication — Part 10102: Nomenclature — Annotated ECG□ ISO/TC 215 사무국의 직접적인 책임 하에 개발 중인 표준 62개 중 15개 목록▷ISO/AWI TR 4419 Health informatics — Reducing clinicians burden▷ISO/DTS 5384 Health informatics - Categorial Structure and Data Elements for the Identification and Exchange of Immunization Data▷ISO/CD TS 5615 Health informatics — Accelerating Safe, Effective and Secure Remote Connected Care and Mobile Health Through Standards-Based Interoperability Solutions Addressing Gaps Revealed by Pandemics▷ISO/DTS 5777 Health informatics — The architecture of internet healthcare service network▷ISO/DTS 5788 Health informatics — Internet healthcare service pattern▷ISO/CD TS 6201.2 Health Informatics — Personalized Digital Health -Framework▷ISO/CD TS 6204 Health Informatics — Categorial structures for representation of Ayurvedic medicinal water — Decocting process in Ayurveda▷ISO/AWI TS 6226 Health informatics — Reference architecture for syndromic surveillance systems for infectious diseases▷ISO/DTR 6231 Health informatics — Standardizing graphical content▷ISO/CD TS 6268-1 Health informatics — Cybersecurity framework for telehealth environments — Part 1: Overview and Concepts▷ISO/AWI TS 6268-2 Health informatics — Cybersecurity framework for telehealth environments — Part 2: Cybersecurity reference models of telehealth▷ISO/CD TS 7122 Health Informatics — Guidelines for exchanging data generated by POCT (Point of Care Testing) devices between screening center and clinical laboratory▷ISO/AWI TS 9166 Health Informatics — Guidelines for self-assessment questionnaire systems▷ISO/DTS 9320 Health informatics — Standardized data set for transfer of hemodialysis patients▷ISO/DTS 9321 Health informatics — General requirements of multi-centre medical data collaborative analysis□ ISO/TC 215 사무국 분과위원회(Subcommittee)의 책임 하에 발행 및 개발 중인 표준 현황▷ISO/TC 215/SC 1 Genomics Informatics ; 발행된 표준 12개, 개발 중인 표준 2개
-
[특집-ISO/IEC JTC 1/SC 17 활동] 26. FIDO Alliance Liaison Statement to ISO/IEC JTC 1/SC 17. October 20232023년 11월30일 ISO/IEC 공동기술위원회 산하 분과위원회 SC 17은 'FIDO Alliance Liaison Statement to ISO/IEC JTC 1/SC 17. October 2023' 문서를 배포했다.ISO/IEC JTC 1/SC 17 카드 및 개인 식별을 위한 보안장치(Cards and security devices for personal identification)는 국제표준화기구(ISO와 국제전기기술위원회(IEC)의 공동 기술 위원회(JTC) ISO/IEC JTC 1의 표준화 분과위원회다.ISO/IEC JTC 1/SC 17의 국제사무국은 영국에 위치한 영국표준협회(BSI)이며 신분증 및 개인 식별 분야 표준을 개발하고 촉진하는 역할을 담당하고 있다.배포된 문서인 'FIDO Alliance Liaison Statement to ISO/IEC JTC 1/SC 17. October 2023'는 ISO/IEC JTC 1/SC 17 워킹그룹 4와 10(WG 4 & 10)을 위한 FIDO 얼라이언스(FIDO Alliance) 연락 문서가 포함됐다.베포된 문서는 FIDO 얼라이언스의 최근 작업 항목 및 프로그램 업데이트 관련된 내용으로 구성됐다. 또한 FIDO 얼라이언스와 관련해 △기술 문서 △인증 프로그램 2024 컨퍼런스 인증 등 3가지 범주를 포함하고 있다.첫째, △클라이언트-인증자(Client to Authenticator, CTAP) 2.2 RD(2023.03. 발행) △FIDO 온보드 장치(FIDO Device Onboard, )FDO) v1.1 제안된 표준(2022.04. 발행) △FDO(FIDO Device Onboard) 어플리케이션 노트 등 기술문서에 관한 것이다.둘째, △FIDO 사용자 인증 프로그램(FIDO User Authentication Programs) △FIDO 원격 신원 확인(IDV) 프로그램(FIDO Remote Identity Verification (IDV) Programs) △FIDO 온보드 장치 인증(FIDO Device Onboard Certification) △FIDO 인증 전문가 프로그램(FIDO Certified Professional Program) 등 인증 프로그램과 관련돼 있다.셋째, FIDO 얼라이언스(FIDO Alliance)가 주최해 개최하는 'Authenticate 2024 Conference'는 FIDO 기반 sign-ins에 중점을 두고 모든 사용자 인증 측면을 다루는 업계 유일의 컨퍼런스다. 컨퍼런스 2024년 연사 모집을 시작했으며 2024년 3월4일까지 제안서를 제출하면 된다. 관련 정보는 https://authenticatecon.com/에 접속해 확인힐 수 있다. - 이하 생략 -
-
‘의약외품 모바일 간편검색서비스’로 안전정보 확인하세요!‘의약외품 모바일 간편검색서비스’가 제공된다. 이에 장애인, 어르신 등 모든 국민이 의약외품 안전정보를 쉽게 확인 가능할 것으로 기대된다. 식품의약품안전처는 쉽고 편리하게 의약외품의 안전정보를 확인할 수 있는 ‘의약외품 모바일 간편검색서비스’를 올해 본격적으로 제공한다고 11일 밝혔다. ‘식의약 규제혁신 2.0’ 디지털 안전관리 혁신의 일환으로 지난해 12월 26일부터 시작된‘의약외품 모바일 간편검색서비스’는 스마트폰으로 의약외품에 표시된 바코드를 인식(스캔)하면 해당 품목의 안전정보를 글자·음성·수어영상으로 제공하는 서비스다. 제공되는 안전정보는 제품명, 제조·수입업소, 효능·효과, 용법·용량, 사용상의주의사항 등으로 시·청각 장애인 등 정보 취약계층의 정보격차 해소에 도움이 될 것으로 기대된다. 현재 의약외품 제조·수입업체에서 바코드 정보를 자율적으로 식약처에 제공한 269개 품목에 대해 글자·음성을 제공, 그중 3개 품목은 수어영상도 제공하고 있으며 향후 서비스 대상 품목을 지속적으로 확대할 예정이다. 특히 269개 품목 중 여성들이 실생활에서 자주 사용하는 ‘생리대’, ‘탐폰’ 등 여성 생리용품이 182개 품목(수어영상 3개)으로 많은 수를 차지하고 있어 생리용품의 선택과 구입에 큰 도움이 될 것으로 기대된다. ‘의약외품 모바일 간편검색서비스’는 ‘의약품안전나라 누리집 접속(nedrug.mfds.go.kr) → 바코드 스캔 버튼 클릭’ 또는 ‘간편검색서비스 바로가기 실행(클릭과 동시에 바코드 스캔 자동 켜짐)’한 뒤 의약외품에 표시된 바코드를 스캔해 사용할 수 있다. 한편 식약처는 올해 2.19억 원의예산을 확보해 의약외품 안전정보를 보다쉽게 확인할 수 있도록 의약외품 모바일 간편검색서비스 사용 편의를 개선하고 음성·수어영상 제작 지원 대상 품목을 확대할 예정이며, 서비스 사용활성화를 위해 대한 안내·홍보도 적극 실시할 계획이다. 식약처 관계자는 “‘의약외품 모바일 간편검색서비스’가 시각·청각 장애인 등 정보취약계층의 보다 안전한 의약외품 사용 환경을 조성하고 정부의 국정 목표인‘따뜻한 동행, 모두가 행복한 사회’를 만드는 데 도움을 줄 것으로 기대한다”고 밝혔다.
-
중앙대, 표준고위과정 12기 모집 안내(~24.02.18.) - 표준전문가 양성과정중앙대 행정대학원은 2024년 2월 18일까지 표준고위과정 12기생을 모집하고 있다고 밝혔다. 표준고위과정은 국가기술표준원과 중앙대 행정대학원이 공동으로 표준전문가를 양성하기 위해 2018년부터 개설해 운영하고 있다.2023년 12월까지 표준고위과정 10기생을 배출했으며 1~10기생을 모두 포함하면 총 438명의 표준 전문가를 양성했다.10기생 수료식에서 국가기술표준원 산업표준혁신과 오광해 국장은 "표준고위 과정을 수료한 분들이 중심이 되어 표준 전문가 네트워크인 표준아너스소사이어티가 자발적으로 운영되고 있다"며 표준고위과정을 입학 및 수료한 전문가들이 다양한 산업에서 상호협력하고 있다고 강조했다.중앙대 행정대학원 관계자는 "전공과 분야가 다른 다양한 전문가들이 만나 지속 가능한 표준 전문가 거버넌스 플랫폼을 구축하고 국제표준에 대한 관심과 깊은 이해를 원하는 사람은 기한 내 적극 지원하면 된다"고 밝혔다. 세부 모집 요강은 다음과 같다.□ 모집 인원 및 지원 자격 ○ 모집 정원 : 50명 내외 ○ 지원 자격 - 기업체 최고경영자 및 임원 - 산·학·연 표준전문가 - 중앙·지방자치단체 표준 담당 공무원 - 비영리단체의 관리자 - 전문직 및 사회 각계의 고위인사 - 기타 이에 준하는 자격을 갖춘 분□ 교육기간 및 장소, 교육 비용 ○ 교육 기간 : 2024.03.22. ~ 2024.12.06.(24주) ○ 교육 시간 : 매주 금요일, 19:00~22:00(80분 2개 강좌) ○ 교육 장소 : 대면/비대면 혼합 - 대면 교육 : 중앙대학교 303관 법학 - 비대면 교육 : ZOOM ○ 교육 비용 : 국가 R&D 사업으로 수강료 무료□ 전형 일정 ○ 원서접수 - 접수기간 : ~ 2021.02.18. ○ 접수방법 - 홈페이지 접수(양식 : https://www.aspp.kr ) ○ 심사 및 합격자 발표 : 서류 심사 및 면접 후 개별 통보
-
[특집-ISO/IEC JTC 1/SC 17 활동] ⑫Project limit date extension request for ISO/IEC 10373-6지난 10월18일 ISO/IEC 공동기술위원회 산하 분과위원회 SC 17은 'Project limit date extension request for ISO/IEC 10373-6' 관련된 문서를 배포했다.ISO/IEC JTC 1/SC 17 카드 및 개인 식별을 위한 보안 장치(Cards and security devices for personal identification)는 국제표준화기구(ISO와 국제전기기술위원회(IEC)의 공동 기술 위원회(JTC) ISO/IEC JTC 1의 표준화 분과위원회다.ISO/IEC JTC 1/SC 17의 국제사무국은 영국에 위치한 영국표준협회(BSI)이며 신분증 및 개인 식별 분야 표준을 개발하고 촉진하는 역할을 담당하고 있다.배포된 문서 'Project limit date extension request for ISO/IEC 10373-6'은 프로젝트가 최대 표준 개발 트랙을 넘어 지연을 초래하는 예상치 못한 문제에 직면했을 때 제한 날짜(DIS 제출 또는 발행) 연장을 요청하기 위한 것이다.작성된 문서는 자동 취소 날짜(ISO/IEC 지침, 파트 1, 통합 ISO 보충 자료, 2023, 2.1.3.2항 참조)로부터 최소 2개월 전에 ISO 기술 프로그램 관리자(TPM)에 제출해 검토 및 결정을 받아야 된다.따라서 TPM에 제출하기 전 위원회 결정(결의안)을 위해 배포됐다. 위원회 간사(Committee Manager)는 STD 18부터 STD 24까지 더 긴 표준 개발 트랙(SDT)로의 진행 요청을 위해 TPM에 보내야 한다.위원회는 전체 프로젝트 기간에 대해 최대 9개월까지 한 번 연장할 수 있으나 권장하고 있는 중간 결과물(예: PAS 및 TS)은 발행해야 된다.ISO/IEC 10373-6 프로젝트가 지연된 이유는 텍스트 개발에 예상보다 오랜 시간이 필요했기 때문이다. ISO/IEC 14443의 몇가지 수정 사항으로 매우 복잡한 내용이 포함된 수백 페이지가 수정됐다.ISO/IEC 10373-6 프로젝트 연장 이유는 지불, 건강, 운송, ID 문서 등 여러 분야의 시장에서 매우 중요하기 때문이다. 해당 제품(수십억 개)이 ISO/IEC 14443 및 ISO/IEC 10373-6에 따라 생산된다. - 이하 생략 -
-
다자간 탄소중립 협의체 ‘기후 클럽’ 공식 출범두바이에서 개최 중인 제28차 유엔기후변화협약당사국총회(11.30-12.12)를 계기로 한 기후 클럽(Climate Club)이 12월 1일(금)에 공식 출범하였다. * 2022년 1월 G7 정상회의 계기 독일이 제안한 협력체이며, 우리나라는 2023년 5월 G7 정상회의에서 기후 클럽 참여 의사를 공식 표명 ‘기후 클럽’은 파리협정의 효과적인 이행과 글로벌 탄소중립 달성을 가속화하기 위한 협의체로 기후변화 문제에 적극적으로 대응하고 있는 36개의 선진국과 개도국이 참여중이다. 현재 기후 클럽은 경제협력개발기구(OECD) 및 국제에너지기구(IEA)에서 임시사무국 역할을 수행 중이며, 추구 공식 사무국이 출범할 예정이다. 창립 회원국은 우리나라와 G7(독일, 미국, 영국, 이탈리아, 일본, 캐나다, 프랑스) 칠레 등을 포함한 총 36개국이다. 특히, 동 기구는 전 세계 에너지 체계 내 탄소 배출량의 25% 이상을 차지하는 산업부문에서의 탈탄소화를 중점 추진 중이며, 산업공정에서 탄소중립을 달성하기 위해 저탄소 기술개발 촉진, 상호인정, 국제표준 형성 등 분야에서 협력을 강화한다는 점에서 우리 정부 및 업계가 중점 추진 중인 무탄소연합(Carbon Free Alliance)과도 그 맥락을 같이하고 있다. 아울러, 기후 클럽이 구축을 제안한 ‘매칭 플랫폼’을 활용해 산업 탈탄소화를 추진하고자 하는 개도국의 수요와 다양한 정부, 국제기구, 민간의 지원을 중개함으로써 보다 효과적인 선진-개도국 간의 협업이 가능해질 것으로 기대되며, 우리 기업들이 새롭게 확대되는 청정경제 시장에서 사업기회를 창출할 수 있을 것으로 기대된다. 또한, 기후클럽은 경제적이고 효과적인 감축 정책 확산을 위해 국제사회 논의를 연계하여 기후행동을 가속화할 수 있을 것으로 보인다. 나아가 회원국이 공동의 목표를 추구하고 탄소중립 정책을 실현하는 관점에서 표준에 대한 국제적 합의를 도출할 것으로 기대된다. 이를 통해 개별 국가의 일방적인 환경정책 도입이 아닌, 협의를 통한 보호정책의 실현이 가능해질 전망이다.
-
[특집-ISO/IEC JTC 1/SC 17 활동] ⑪Project limit date extension request for ISO/IEC 18103-7지난 10월18일 ISO/IEC 공동기술위원회 산하 분과위원회 SC 17은 'Project limit date extension request for ISO/IEC 18103-7' 관련된 문서를 배포했다.ISO/IEC JTC 1/SC 17 카드 및 개인 식별을 위한 보안 장치(Cards and security devices for personal identification)는 국제표준화기구(ISO와 국제전기기술위원회(IEC)의 공동 기술 위원회(JTC) ISO/IEC JTC 1의 표준화 분과위원회다.ISO/IEC JTC 1/SC 17의 국제사무국은 영국에 위치한 영국표준협회(BSI)이며 신분증 및 개인 식별 분야 표준을 개발하고 촉진하는 역할을 담당하고 있다.배포된 문서는 'Project limit date extension request for ISO/IEC 18103-7'은 프로젝트가 최대 표준 개발 트랙을 넘어 지연을 초래하는 예상치 못한 문제에 직면했을 때 제한 날짜(DIS 제출 또는 발행) 연장을 요청과 관련됐다.작성된 문서는 자동 취소 날짜(ISO/IEC 지침, 파트 1, 통합 ISO 보충 자료, 2023, 2.1.3.2항 참조)로부터 최소 2개월 전에 ISO 기술 프로그램 관리자(TPM)에 제출해 검토 및 결정을 받아야 된다.따라서 TPM에 제출하기 전 위원회 결정(결의안)을 위해 배포됐다. 위원회 간사(Committee Manager)는 STD 18부터 STD 24까지 더 긴 표준 개발 트랙(SDT)로의 진행 요청을 위해 TPM에 보내야 한다.위원회는 전체 프로젝트 기간에 대해 최대 9개월까지 한 번 연장할 수 있으나 권장하고 있는 중간 결과물(예: PAS 및 TS)은 발행해야 된다. - 이하 생략 -
-
[기획-디지털 ID 표준] ⑯산업단체와 포럼 - SOG-IS(Senior Officials Group-Information Systems Security)디지털 ID(Digital Identity) 분야에서 상호운용(interoperable)이 가능하고 안전한 서비스 보장을 위한 표준에 대한 수요가 증가하고 있다. 다양한 표준 조직 및 산업 기관이 활동하는 이유다.디지털 ID 표준을 개발하는 곳은 유럽표준화기구(European Standardisation Organistions), 국제표준화기구(International Standardisation Organisations), 상업 포럼 및 컨소시엄, 국가기관 등 다양하다.산업단체와 포럼은 공식적으로 표준화 조직으로 간주되지 않지만 디지털 ID 영역을 포함한 특정 영역에서는 사실상의 표준을 제공하고 있다.몇몇의 경우 이들 단체들이 추가 비준을 위해 자신들이 생산한 사양을 ISO/IEC, ITU 통신 표준화 부문(ITU-T), ETSI 등 표준 기관에 제출할 수 있다.이러한 산업단체 및 포럼에는 △인증기관브라우저 포럼(Certification Authority Browser Forum, CA/Browser Forum) △클라우드 서명 컨소시엄(Cloud Signature Consortium, CSC) △국제자금세탁방지기구(Financial Action Task Force, FATF) △신속온라인인증(Fast Identity Online, FIDO) △국제인터넷표준화기구(Internet Engineering Task Force, IETF) △구조화 정보 표준 개발기구(오아시스)(Organization for the Advancement of Structured Information Standards, OASIS) △오픈ID(OpenID) △SOG-IS(Senior Officials Group-Information Systems Security) △W3C(World Wide Web Consortium) 등이다.SOG-IS(Senior Officials Group-Information Systems Security)는 유럽연합(EU) 또는 유럽 자유 무역 연합(European Free Trade Association, EFTA) 국가의 정부 조직 또는 정부기관간 협정으로 이사회 결정 92/242/EEC (12) 및 후속 이사회 권장 사항 95/144/EC (13)에 따라 작성됐다.SOG-IS 암호 워킹그룹(Crypto Working Group)이 발행한 'SOG-IS Crypto Evaluation Scheme Agreed Cryptographic Mechanisms' 문서는 주로 개발자와 평가자를 대상으로 작성됐다.어떤 암호화 메커니즘이 동의된 것으로 인식되는지, 즉 SOG-IS 암호화 평가 체계의 모든 SOG-IS 참가자가 수락할 순비가 됐는지 지정하는 것을 목적으로 하고 있다.'SOG-IS Crypto Evaluation Scheme Agreed Cryptographic Mechanisms' 문서의 목차를 살펴보면 다음과 같다.목차(Table of contents)1. Introduction1.1 Objective1.2 Classification of Cryptographic Mechanisms1.3 Security Level1.4 Organization of the Document1.5 Related Documents2. Symmetric Atomic Primitives2.1 Block Ciphers2.2 Stream Ciphers2.3 Hash Functions2.4 Secret Sharing3. Symmetric Constructions3.1 Confidentiality Modes of Operation: Encryption/Decryption Modes3.2 Specific Confidentiality Modes: Disk Encryption3.3 Integrity Modes: Message Authentication Codes3.4 Symmetric Entity Authentication Schemes3.5 Authenticated Encryption3.6 Key Protection3.7 Key Derivation Functions3.8 Password Protection/Password Hashing Mechanisms4. Asymmetric Atomic Primitives4.1 RSA/Integer Factorization4.2 Discrete Logarithm in Finite Fields4.3 Discrete Logarithm in Elliptic Curves4.4 Other Intractable Problems5. Asymmetric Constructions5.1 Asymmetric Encryption Scheme5.2 Digital Signature5.3 Asymmetric Entity Authentication Schemes5.4 Key Establishment6. Random Generator6.1 Random Source6.2 Deterministic Random Bit Generator6.3 Random Number Generator with Specific Distribution7. Key Management7.1 Key Generation7.2 Key Storage and Transport7.3 Key Use7.4 Key Destruction8. Person AuthenticationA Glossary
-
[기획-디지털 ID 표준] ⑮산업단체와 포럼 - 오픈ID(OpenID)디지털 ID(Digital Identity) 분야에서 상호운용(interoperable)이 가능하고 안전한 서비스 보장을 위한 표준에 대한 수요가 증가하고 있다. 다양한 표준 조직 및 산업 기관이 활동하는 이유다.디지털 ID 표준을 개발하는 곳은 유럽표준화기구(European Standardisation Organistions), 국제표준화기구(International Standardisation Organisations), 상업 포럼 및 컨소시엄, 국가기관 등 다양하다.산업단체와 포럼은 공식적으로 표준화 조직으로 간주되지 않지만 디지털 ID 영역을 포함한 특정 영역에서는 사실상의 표준을 제공하고 있다.몇몇의 경우 이들 단체들이 추가 비준을 위해 자신들이 생산한 사양을 ISO/IEC, ITU 통신 표준화 부문(ITU-T), ETSI 등 표준 기관에 제출할 수 있다.이러한 산업단체 및 포럼에는 △인증기관브라우저 포럼(Certification Authority Browser Forum, CA/Browser Forum) △클라우드 서명 컨소시엄(Cloud Signature Consortium, CSC) △국제자금세탁방지기구(Financial Action Task Force, FATF) △신속온라인인증(Fast Identity Online, FIDO) △국제인터넷표준화기구(Internet Engineering Task Force, IETF) △구조화 정보 표준 개발기구(오아시스)(Organization for the Advancement of Structured Information Standards, OASIS) △오픈ID(OpenID) △SOG-IS(Senior Officials Group-Information Systems Security) △W3C(World Wide Web Consortium) 등이다.오픈ID(OpenID)는 개인 및 기업의 비영리 국제 표준화 조직으로 OpenID(개방형 표준 및 분산 인증 프로토콜)를 활성화, 홍보, 보호하기 위해 노력하고 있다.오픈ID 코넥트 코어(OpenID Connect Core)는 핵심 OpenID 기능을 정의하고 있다. OpenID 기능은 OAuth 2.0 기반에 구축된 인증과 최종 사용자에 대한 정보를 전달하기 위한 클레임의 사용이다. 추가적인 기술 사양 문서는 검증 가능한 자격 증명 및 검증 가능한 프리젠테이션의 발급을 확장하기 위해 작성됐다. 또한 OpenID Connect 사용에 대한 보안 및 개인 정보 보호 고려 사항에 대해 설명하고 있다.아래는 오픈ID가 발행한 'OpenID Connect Core 1.0 incorporating errata set 1' 목차 내용이다.■ 목차(Table of Contents)1. Introduction1.1. Requirements Notation and Conventions1.2. Terminology1.3. Overview2. ID Token3. Authentication3.1. Authentication using the Authorization Code Flow3.1.1. Authorization Code Flow Steps3.1.2. Authorization Endpoint3.1.2.1. Authentication Request3.1.2.2. Authentication Request Validation3.1.2.3. Authorization Server Authenticates End-User3.1.2.4. Authorization Server Obtains End-User Consent/Authorization3.1.2.5. Successful Authentication Response3.1.2.6. Authentication Error Response3.1.2.7. Authentication Response Validation3.1.3. Token Endpoint3.1.3.1. Token Request3.1.3.2. Token Request Validation3.1.3.3. Successful Token Response3.1.3.4. Token Error Response3.1.3.5. Token Response Validation3.1.3.6. ID Token3.1.3.7. ID Token Validation3.1.3.8. Access Token Validation3.2. Authentication using the Implicit Flow3.2.1. Implicit Flow Steps3.2.2. Authorization Endpoint3.2.2.1. Authentication Request3.2.2.2. Authentication Request Validation3.2.2.3. Authorization Server Authenticates End-User3.2.2.4. Authorization Server Obtains End-User Consent/Authorization3.2.2.5. Successful Authentication Response3.2.2.6. Authentication Error Response3.2.2.7. Redirect URI Fragment Handling3.2.2.8. Authentication Response Validation3.2.2.9. Access Token Validation3.2.2.10. ID Token3.2.2.11. ID Token Validation3.3. Authentication using the Hybrid Flow3.3.1. Hybrid Flow Steps3.3.2. Authorization Endpoint3.3.2.1. Authentication Request3.3.2.2. Authentication Request Validation3.3.2.3. Authorization Server Authenticates End-User3.3.2.4. Authorization Server Obtains End-User Consent/Authorization3.3.2.5. Successful Authentication Response3.3.2.6. Authentication Error Response3.3.2.7. Redirect URI Fragment Handling3.3.2.8. Authentication Response Validation3.3.2.9. Access Token Validation3.3.2.10. Authorization Code Validation3.3.2.11. ID Token3.3.2.12. ID Token Validation3.3.3. Token Endpoint3.3.3.1. Token Request3.3.3.2. Token Request Validation3.3.3.3. Successful Token Response3.3.3.4. Token Error Response3.3.3.5. Token Response Validation3.3.3.6. ID Token3.3.3.7. ID Token Validation3.3.3.8. Access Token3.3.3.9. Access Token Validation4. Initiating Login from a Third Party5. Claims5.1. Standard Claims5.1.1. Address Claim5.1.2. Additional Claims5.2. Claims Languages and Scripts5.3. UserInfo Endpoint5.3.1. UserInfo Request5.3.2. Successful UserInfo Response5.3.3. UserInfo Error Response5.3.4. UserInfo Response Validation5.4. Requesting Claims using Scope Values5.5. Requesting Claims using the "claims" Request Parameter5.5.1. Individual Claims Requests5.5.1.1. Requesting the "acr" Claim5.5.2. Languages and Scripts for Individual Claims5.6. Claim Types5.6.1. Normal Claims5.6.2. Aggregated and Distributed Claims5.6.2.1. Example of Aggregated Claims5.6.2.2. Example of Distributed Claims5.7. Claim Stability and Uniqueness6. Passing Request Parameters as JWTs6.1. Passing a Request Object by Value6.1.1. Request using the "request" Request Parameter6.2. Passing a Request Object by Reference6.2.1. URL Referencing the Request Object6.2.2. Request using the "request_uri" Request Parameter6.2.3. Authorization Server Fetches Request Object6.2.4. "request_uri" Rationale6.3. Validating JWT-Based Requests6.3.1. Encrypted Request Object6.3.2. Signed Request Object6.3.3. Request Parameter Assembly and Validation7. Self-Issued OpenID Provider7.1. Self-Issued OpenID Provider Discovery7.2. Self-Issued OpenID Provider Registration7.2.1. Providing Information with the "registration" Request Parameter7.3. Self-Issued OpenID Provider Request7.4. Self-Issued OpenID Provider Response7.5. Self-Issued ID Token Validation8. Subject Identifier Types8.1. Pairwise Identifier Algorithm9. Client Authentication10. Signatures and Encryption10.1. Signing10.1.1. Rotation of Asymmetric Signing Keys10.2. Encryption10.2.1. Rotation of Asymmetric Encryption Keys11. Offline Access12. Using Refresh Tokens12.1. Refresh Request12.2. Successful Refresh Response12.3. Refresh Error Response13. Serializations13.1. Query String Serialization13.2. Form Serialization13.3. JSON Serialization14. String Operations15. Implementation Considerations15.1. Mandatory to Implement Features for All OpenID Providers15.2. Mandatory to Implement Features for Dynamic OpenID Providers15.3. Discovery and Registration15.4. Mandatory to Implement Features for Relying Parties15.5. Implementation Notes15.5.1. Authorization Code Implementation Notes15.5.2. Nonce Implementation Notes15.5.3. Redirect URI Fragment Handling Implementation Notes15.6. Compatibility Notes15.6.1. Pre-Final IETF Specifications15.6.2. Google "iss" Value15.7. Related Specifications and Implementer's Guides16. Security Considerations16.1. Request Disclosure16.2. Server Masquerading16.3. Token Manufacture/Modification16.4. Access Token Disclosure16.5. Server Response Disclosure16.6. Server Response Repudiation16.7. Request Repudiation16.8. Access Token Redirect16.9. Token Reuse16.10. Eavesdropping or Leaking Authorization Codes (Secondary Authenticator Capture)16.11. Token Substitution16.12. Timing Attack16.13. Other Crypto Related Attacks16.14. Signing and Encryption Order16.15. Issuer Identifier16.16. Implicit Flow Threats16.17. TLS Requirements16.18. Lifetimes of Access Tokens and Refresh Tokens16.19. Symmetric Key Entropy16.20. Need for Signed Requests16.21. Need for Encrypted Requests17. Privacy Considerations17.1. Personally Identifiable Information17.2. Data Access Monitoring17.3. Correlation17.4. Offline Access18. IANA Considerations18.1. JSON Web Token Claims Registration18.1.1. Registry Contents18.2. OAuth Parameters Registration18.2.1. Registry Contents18.3. OAuth Extensions Error Registration18.3.1. Registry Contents19. References19.1. Normative References19.2. Informative ReferencesAppendix A. Authorization ExamplesA.1. Example using response_type=codeA.2. Example using response_type=id_tokenA.3. Example using response_type=id_token tokenA.4. Example using response_type=code id_tokenA.5. Example using response_type=code tokenA.6. Example using response_type=code id_token tokenA.7. RSA Key Used in ExamplesAppendix B. AcknowledgementsAppendix C. Notices§ Authors' Addresses
-
[기획-디지털 ID 표준] ⑭산업단체와 포럼 - 오아시스(OASIS)디지털 ID(Digital Identity) 분야에서 상호운용(interoperable)이 가능하고 안전한 서비스 보장을 위한 표준에 대한 수요가 증가하고 있다. 다양한 표준 조직 및 산업 기관이 활동하는 이유다.디지털 ID 표준을 개발하는 곳은 유럽표준화기구(European Standardisation Organistions), 국제표준화기구(International Standardisation Organisations), 상업 포럼 및 컨소시엄, 국가기관 등 다양하다.산업단체와 포럼은 공식적으로 표준화 조직으로 간주되지 않지만 디지털 ID 영역을 포함한 특정 영역에서는 사실상의 표준을 제공하고 있다.몇몇의 경우 이들 단체들이 추가 비준을 위해 자신들이 생산한 사양을 ISO/IEC, ITU 통신 표준화 부문(ITU-T), ETSI 등 표준 기관에 제출할 수 있다.이러한 산업단체 및 포럼에는 △인증기관브라우저 포럼(Certification Authority Browser Forum, CA/Browser Forum) △클라우드 서명 컨소시엄(Cloud Signature Consortium, CSC) △국제자금세탁방지기구(Financial Action Task Force, FATF) △신속온라인인증(Fast Identity Online, FIDO) △국제인터넷표준화기구(Internet Engineering Task Force, IETF) △구조화 정보 표준 개발기구(오아시스)(Organization for the Advancement of Structured Information Standards, OASIS) △오픈ID(OpenID) △SOG-IS(Senior Officials Group-Information Systems Security) △W3C(World Wide Web Consortium) 등이다.구조화 정보 표준 개발기구(Organization for the Advancement of Structured Information Standards, OASIS)는 공급업체와 사용자의 컨소시엄으로 시작됐다.오늘날 사이버보안(cybersecurity), 블록체인(blockchain), 사물인터넷(internet of things, IoT), 비상 경영(emergency management), 클라우드 컴퓨팅(cloud computing) 등 프로젝트를 발전시키는 대규모 비영리 표준 조직이다.오아시스는 '디지털 서명 서비스 핵심 프로토콜, 요소, 바인딩'과 같은 디지털 서명과 관련된 프로토콜, 프로필 등 기술 사양을 개발해왔다.오아시스는 ISO에 협력하고 있는 조직으로 각 기술위원회(TC) 또는 분과위원회(SC)가 다루는 문제에 대해 기술위원회(TC) 또는 분과위원회(SC)의 업무에 효과적으로 기여하는 조직(A liaisons)이다.기여하고 있는 기술위원회 및 분과위원회는 다음과 같다.▷ISO/IEC JTC 1/SC 6 시스템 간 통신 및 정보 교환▷ISO/IEC JTC 1/SC 34 문서 설명 및 처리 언어▷ISO/IEC JTC 1/SC 38 클라우드 컴퓨팅 및 분산 플랫폼▷ISO/IEC JTC 1/SC 40 IT 서비스 관리 및 IT 거버넌스▷ISO/TC 12 수량 및 단위▷ISO/TC 37 언어 및 용어▷ISO/TC 37/SC 5 번역, 통역 및 관련 기술▷ISO/TC 46/SC 4 기술적 상호 운용성▷ISO/TC 154 상업, 산업 및 행정 분야의 프로세스, 데이터 요소 및 문서▷ISO/TC 184/SC 4 산업 데이터▷ISO/TC 211 지리정보/지리학또한 오아시스는 2005년 10월 21일 Working Draft 34에서 Digital Signature Service Core Protocols, Elements, and Bindings Version 1.0을 발표했다.이후 2019년 12월 11일 'Digital Signature Service Core Protocols, Elements, and Bindings Version 2.0 Committee Specification 02'가 발표됐다.버전 2.0의 목차를 살펴보면 다음과 같다.■ 목차(Table of Contents) 1 Introduction 1.1 IPR Policy 1.2 Terminology 1.2.1 Terms and Definitions 1.2.2 Abbreviated Terms 1.3 Normative References 1.4 Non-Normative References 1.5 Typographical Conventions 1.6 DSS Overview (Non-normative) 2 Design Considerations 2.1 Version 2.0 goal [non-normative] 2.2 Transforming DSS 1.0 into 2.0 2.2.1 Circumventing xs:any 2.2.2 Substituting the mixed Schema Attribute 2.2.3 Introducing the NsPrefixMappingType Component 2.2.4 Imported XML schemes 2.2.5 Syntax variants 2.2.6 JSON Syntax Extensions 2.3 Construction Principles 2.3.1 Multi Syntax approach 2.4 Schema Organization and Namespaces 2.5 DSS Component Overview 2.5.1 Schema Extensions 3 Data Type Models 3.1 Boolean Model 3.2 Integer Model 3.3 String Model 3.4 Binary Data Model 3.5 URI Model 3.6 Unique Identifier Model 3.7 Date and Time Model 3.8 Lang Model 4 Data Structure Models 4.1 Data Structure Models defined in this document 4.1.1 Component NsPrefixMapping 4.1.1.1 NsPrefixMapping – JSON Syntax 4.1.1.2 NsPrefixMapping – XML Syntax 4.2 Data Structure Models defined in this document 4.2.1 Component InternationalString 4.2.1.1 InternationalString – JSON Syntax 4.2.1.2 InternationalString – XML Syntax 4.2.2 Component DigestInfo 4.2.2.1 DigestInfo – JSON Syntax 4.2.2.2 DigestInfo – XML Syntax 4.2.3 Component AttachmentReference 4.2.3.1 AttachmentReference – JSON Syntax 4.2.3.2 AttachmentReference – XML Syntax 4.2.4 Component Any 4.2.4.1 Any – JSON Syntax 4.2.4.2 Any – XML Syntax 4.2.5 Component Base64Data 4.2.5.1 Base64Data – JSON Syntax 4.2.5.2 Base64Data – XML Syntax 4.2.6 Component SignaturePtr 4.2.6.1 SignaturePtr – JSON Syntax 4.2.6.2 SignaturePtr – XML Syntax 4.2.7 Component Result 4.2.7.1 Result – JSON Syntax 4.2.7.2 Result – XML Syntax 4.2.8 Component OptionalInputs 4.2.8.1 OptionalInputs – JSON Syntax 4.2.8.2 OptionalInputs – XML Syntax 4.2.9 Component OptionalOutputs 4.2.9.1 OptionalOutputs – JSON Syntax 4.2.9.2 OptionalOutputs – XML Syntax 4.2.10 Component RequestBase 4.2.10.1 RequestBase – JSON Syntax 4.2.10.2 RequestBase – XML Syntax 4.2.11 Component ResponseBase 4.2.11.1 ResponseBase – JSON Syntax 4.2.11.2 ResponseBase – XML Syntax 4.3 Operation requests and responses 4.3.1 Component SignRequest 4.3.1.1 SignRequest – JSON Syntax 4.3.1.2 SignRequest – XML Syntax 4.3.2 Component SignResponse 4.3.2.1 SignResponse – JSON Syntax 4.3.2.2 SignResponse – XML Syntax 4.3.3 Component VerifyRequest 4.3.3.1 VerifyRequest – JSON Syntax 4.3.3.2 VerifyRequest – XML Syntax 4.3.4 Component VerifyResponse 4.3.4.1 VerifyResponse – JSON Syntax 4.3.4.2 VerifyResponse – XML Syntax 4.3.5 Component PendingRequest 4.3.5.1 PendingRequest – JSON Syntax 4.3.5.2 PendingRequest – XML Syntax 4.4 Optional data structures defined in this document 4.4.1 Component RequestID 4.4.1.1 RequestID – JSON Syntax 4.4.1.2 RequestID – XML Syntax 4.4.2 Component ResponseID 4.4.2.1 ResponseID – JSON Syntax 4.4.2.2 ResponseID – XML Syntax 4.4.3 Component OptionalInputsBase 4.4.3.1 OptionalInputsBase – JSON Syntax 4.4.3.2 OptionalInputsBase – XML Syntax 4.4.4 Component OptionalInputsSign 4.4.4.1 OptionalInputsSign – JSON Syntax 4.4.4.2 OptionalInputsSign – XML Syntax 4.4.5 Component OptionalInputsVerify 4.4.5.1 OptionalInputsVerify – JSON Syntax 4.4.5.2 OptionalInputsVerify – XML Syntax 4.4.6 Component OptionalOutputsBase 4.4.6.1 OptionalOutputsBase – JSON Syntax 4.4.6.2 OptionalOutputsBase – XML Syntax 4.4.7 Component OptionalOutputsSign 4.4.7.1 OptionalOutputsSign – JSON Syntax 4.4.7.2 OptionalOutputsSign – XML Syntax 4.4.8 Component OptionalOutputsVerify 4.4.8.1 OptionalOutputsVerify – JSON Syntax 4.4.8.2 OptionalOutputsVerify – XML Syntax 4.4.9 Component ClaimedIdentity 4.4.9.1 ClaimedIdentity – JSON Syntax 4.4.9.2 ClaimedIdentity – XML Syntax 4.4.10 Component Schemas 4.4.10.1 Schemas – JSON Syntax 4.4.10.2 Schemas – XML Syntax 4.4.11 Component IntendedAudience 4.4.11.1 IntendedAudience – JSON Syntax 4.4.11.2 IntendedAudience – XML Syntax 4.4.12 Component KeySelector 4.4.12.1 KeySelector – JSON Syntax 4.4.12.2 KeySelector – XML Syntax 4.4.13 Component X509Digest 4.4.13.1 X509Digest – JSON Syntax 4.4.13.2 X509Digest – XML Syntax 4.4.14 Component PropertiesHolder 4.4.14.1 PropertiesHolder – JSON Syntax 4.4.14.2 PropertiesHolder – XML Syntax 4.4.15 Component Properties 4.4.15.1 Properties – JSON Syntax 4.4.15.2 Properties – XML Syntax 4.4.16 Component Property 4.4.16.1 Property – JSON Syntax 4.4.16.2 Property – XML Syntax 4.4.17 Component IncludeObject 4.4.17.1 IncludeObject – JSON Syntax 4.4.17.2 IncludeObject – XML Syntax 4.4.18 Component SignaturePlacement 4.4.18.1 SignaturePlacement – JSON Syntax